9장. 빠르고 싸게 만들기

출처: 『AI 엔지니어링』(Chip Huyen 지음) | 원서: AI Engineering (O'Reilly) — 본 입문판은 PDF 원문(9장 "추론 최적화")에서 직접 풀어 썼다.

코드는 분위기만 — Python·API 같은 말은 몰라도 됩니다. 표의 '비유'와 '위험'만 봐도 충분해요.

0. 이 장의 새 단어

0장 용어집에 없는 말은 딱 3개다.

이 3개만 알면 이 장은 다 읽힌다.

추론(inference)

한 문장 뜻 — 이미 만들어진 모델에 입력을 넣어 답을 받아내는 일. 모델을 '쓰는' 순간.

일상비유 — 자판기에서 음료 뽑기. 자판기를 만드는 일(학습)은 끝났고, 동전을 넣고 버튼을 누르면(입력) 음료가 나온다(답).

한 줄 예 —

# 학습은 끝났고, 이제 그냥 답만 받음
answer = model.ask("이 문장 요약해줘")  # 이게 추론

지연 시간(latency)

한 문장 뜻 — 질문을 보낸 순간부터 답을 다 받을 때까지 걸리는 시간.

일상비유 — 식당에서 주문하고 음식 나올 때까지의 시간. 짧을수록 손님이 안 떠난다.

한 줄 예 —

# 묻기 직전과 답 받은 직후, 시계를 한 번씩 본다
# 두 시각을 빼면 = 내가 기다린 시간(이게 지연 시간)
start = now(); answer = model.ask("..."); latency = now() - start

처리량(throughput)

한 문장 뜻 — 같은 시간에 몇 명분(몇 토큰)을 만들어낼 수 있는지. 한 번에 얼마나 많이 쳐내느냐.

일상비유 — 식당이 한 시간에 손님 몇 명을 받느냐. 회전율이다.

한 줄 예 —

# 1초에 토큰 몇 개를 뽑아내나
throughput = tokens_made / seconds  # 클수록 좋음(보통 비용도 싸짐)

이런 적 있죠?

주말에 만든 데모는 멋지게 돌았다.

그런데 사용자에게 내놓으니 답 하나 받는 데 5초가 걸린다.

다들 기다리다 창을 닫는다.

게다가 한 달 클라우드 요금이 월급만큼 나왔다.

# 답은 맞다. 그런데...
answer = model.ask("내일 주가 예측해줘")  # 5초 걸림 → 그땐 이미 늦음

모델이 아무리 똑똑해도 너무 느리면 쓸모가 없고, 너무 비싸면 못 쓴다.

그래서 같은 답을 더 빠르고 더 싸게 받아내는 기술이 필요하다.

이것이 이 장의 주제, 빠르고 싸게 만들기다.

원서는 이걸 '추론 최적화'라 부른다.

새 모델은 계속 나타났다 사라지지만, "더 좋게·더 싸게·더 빠르게"라는 목표는 안 변한다.

이 장에서 딱 4가지만

① 왜 — 느리거나 비싸면 똑똑한 모델도 못 쓴다. 그래서 빠르고 싸게 만든다.

② 어디가 느린지 재는 자 — 지연 시간·처리량·활용률. 재야 고친다.

③ 모델 자체 다듬기 — 모델을 작게·똑똑하게 고쳐 빠르게.

④ 굴리는 법 다듬기 — 모델은 그대로 두고, 요청 나르는 방식만 바꿔 빠르게.

개념 1 — 둘 중 어디서 막히나 (연산 제약 vs 메모리 대역폭 제약)

망가지는 장면

"GPU를 더 좋은 걸로 바꿨는데 빨라지질 않네?"

비싼 걸로 바꿨는데 그대로다.

이유는 간단하다. 막힌 곳이 거기가 아니었다.

최적화는 막힌 곳(병목)을 찾아 뚫는 일이다.

엉뚱한 데를 뚫으면 돈만 쓴다.

일상비유

고속도로 정체. 막히는 이유는 둘 중 하나다.

하나는 차로가 좁아서(연산이 느려서) 막힌다.

다른 하나는 나들목이 좁아서(데이터가 못 들어와서) 막힌다.

차로를 넓혀야 할 때 나들목을 고치면 헛수고다.

한 문장 정의 — 연산 제약은 계산량 때문에 느린 것이고, 메모리 대역폭 제약은 데이터를 옮기는 속도 때문에 느린 것이다. 막힌 쪽을 먼저 알아야 맞는 약을 쓴다.

단계별 예시

(1) 완성 예 — 글을 한 글자씩 만드는 언어 모델은 보통 메모리 대역폭 제약이다. 글자 하나 만들 때마다 거대한 모델 짐을 메모리에서 꺼내 와야 해서, 옮기는 데 시간이 다 간다.

(2) 부분 완성 — 그림을 그려내는 이미지 생성 모델은 계산을 엄청 많이 한다. 그래서 이건 ( ) 제약이다. → 답: 연산.

(3) 독립 적용 — 사진 한 장에 무거운 수학 계산을 잔뜩 하는 작업이 느리다. 칩을 '연산 빠른 것'과 '대역폭 넓은 것' 중 어느 쪽으로 바꿔야 할까? → 연산 빠른 것.

한 걸음 더 ▸ (지금 몰라도 됨) 둘 중 어디서 막히는지 한눈에 보는 차트가 있다. 모양이 지붕 같아서 '루프라인 차트'라 부른다. 지금은 "막힌 곳부터 찾는다"만 기억하면 된다.

개념 2 — 글을 만드는 두 박자 (프리필과 디코딩)

망가지는 장면

"첫 글자는 금방 나오는데, 그다음부터는 한 글자씩 느릿느릿 나오네?"

고장이 아니다.

언어 모델이 답을 만드는 방식이 원래 두 박자로 나뉘기 때문이다.

일상비유

받아쓰기 시험.

먼저 문제를 한 번에 쭉 읽는다(프리필). 이건 빠르다. 한꺼번에 처리하니까.

그다음 답을 한 글자씩 써 내려간다(디코딩). 이건 느리다. 앞 글자를 봐야 다음 글자를 쓰니까.

한 문장 정의 — 프리필은 입력을 한꺼번에 읽는 빠른 박자(연산 제약), 디코딩은 출력을 한 토큰씩 만드는 느린 박자(메모리 대역폭 제약)다.

단계별 예시

(1) 완성 예 — "카오스의 작가는?"이라고 물으면, 모델은 질문 전체를 한 번에 읽고(프리필) → "제임스"→"글릭이"→"썼다"를 한 토큰씩 만든다(디코딩).

(2) 부분 완성 — 첫 글자가 빨리 나오는 건 ( ) 박자 덕분이고, 그다음이 느린 건 ( ) 박자 때문이다. → 프리필 / 디코딩.

(3) 독립 적용 — 답이 1,000글자로 아주 길다. 두 박자 중 어느 쪽이 전체 시간을 거의 다 잡아먹을까? → 디코딩.

개념 3 — 빨리 받기 vs 많이 받기 (지연 시간과 처리량)

망가지는 장면

"요청을 한꺼번에 묶어서 처리했더니 전체 속도는 빨라졌는데, 한 사람 한 사람은 더 오래 기다리네?"

둘 다 좋게 만들기 어렵다.

빨리 받기와 많이 받기는 서로 당긴다.

일상비유

자기 차 vs 버스.

자기 차로 가면 나 혼자는 빠르다(지연 시간 짧음). 하지만 도로가 차로 꽉 찬다.

버스로 다 같이 가면 사람은 많이 나른다(처리량 높음). 대신 정류장마다 서니 나는 더 걸린다.

한 문장 정의 — 지연 시간은 한 명이 답을 받기까지의 시간, 처리량은 같은 시간에 처리하는 양이며, 보통 하나를 좋게 하면 다른 하나가 나빠지는 트레이드오프다.

단계별 예시

(1) 완성 예 — 챗봇은 사람이 눈앞에서 기다린다. 그래서 지연 시간을 우선해 바로바로 답한다.

(2) 부분 완성 — 밤사이 보고서 1만 건을 한꺼번에 돌리는 작업은, 아무도 안 기다리니까 ( )을 우선해 묶어서 싸게 처리한다. → 처리량.

(3) 독립 적용 — "첫 토큰까지 시간(TTFT)"은 첫 글자가 나오는 속도, "출력 토큰당 시간(TPOT)"은 그다음 글자들이 나오는 속도다. 챗봇에서 사용자가 "버벅인다"고 느낀다면 둘 중 무엇이 나쁜 걸까? → TPOT(그다음 글자들이 느린 것).

한 걸음 더 ▸ (지금 몰라도 됨) 평균만 보면 속는다. 10건 중 9건이 100ms인데 1건이 3,000ms면 평균은 390ms로 뻥튀기된다. 그래서 "절반은 이 시간 안에 끝난다(p50)" 같은 백분위수로 본다. 지금은 "평균은 거짓말한다"만 알면 된다.

개념 4 — 일하는 시간 ≠ 잘 쓰는 시간 (활용률)

망가지는 장면

"GPU가 100% 돌고 있다고 떠서 안심했는데, 알고 보니 능력의 1%만 쓰고 있었네?"

'바쁘다'와 '제대로 쓴다'는 다른 말이다.

일상비유

8차로 고속도로에 차가 한 대만 굴러간다.

도로는 '사용 중'이다. 하지만 8차로를 한 대가 쓰는 건 엄청난 낭비다.

도로가 바쁜 것과, 도로를 알차게 쓰는 것은 다르다.

한 문장 정의 — 활용률은 자원을 얼마나 알차게 쓰는지를 재는 값으로, '돌고 있는가'가 아니라 '능력 대비 얼마나 뽑아내는가'를 봐야 한다.

단계별 예시

(1) 완성 예 — 칩이 초당 100토큰을 낼 수 있는데 실제로는 20토큰만 낸다면, 능력의 20%만 쓰는 셈이다(MFU 20%).

(2) 부분 완성 — 대역폭이 1TB/s인 칩에서 실제로 500GB/s만 쓰면, 대역폭 활용률은 ( )%다. → 50.

(3) 독립 적용 — 활용률만 높이는 게 목표일까? 아니다. 진짜 목표는 "더 빠르고 더 싸게"다. 활용률이 높아도 비용과 시간이 같이 늘면 ( )이다. → 헛수고.

개념 5 — 칩 고르기 (AI 가속기)

망가지는 장면

"CPU로 모델을 돌렸더니 답 하나에 몇 시간이 걸렸다."

CPU가 나빠서가 아니다.

일에 안 맞는 칩을 썼기 때문이다.

일상비유

일꾼 비유.

CPU는 똑똑한 일꾼 몇 명이다. 복잡한 일을 순서대로 똑 부러지게 한다.

GPU는 단순한 일꾼 수천 명이다. 똑같이 쪼갤 수 있는 일을 한꺼번에 와르르 해치운다.

모델 계산은 잘게 쪼개지는 일이라, 수천 명(GPU)이 유리하다.

한 문장 정의 — AI 가속기는 AI 계산에 맞게 만든 칩으로, 잘게 쪼개지는 계산을 한꺼번에 처리하는 GPU가 대표 주자다.

단계별 예시

(1) 완성 예 — 모델 계산의 90% 이상은 행렬 곱이다. 행렬 곱은 작은 곱셈을 잔뜩 동시에 하는 일이라, 수천 코어의 GPU가 딱 맞는다.

(2) 부분 완성 — 운영체제 실행처럼 순서대로 처리해야 하는 일은 ( )가 더 낫다. → CPU.

(3) 독립 적용 — 칩을 살 때 던질 핵심 질문 3가지: ① 이 일을 ( )가? ② 얼마나 ( )가? ③ 얼마나 ( )가? → 실행할 수 있는가 / 걸리는가 / 비용이 드는가.

한 걸음 더 ▸ (지금 몰라도 됨) GPU 안에는 빠른 메모리(가까운 작은 칸)와 느린 메모리(먼 큰 칸)가 층층이 있다. 최적화의 절반은 "자주 쓰는 데이터를 가까운 칸에 두기"다. 그리고 이 칩들은 전기를 어마어마하게 먹는다(H100 한 대가 미국 가정 1년치 가까이). 지금은 "칩은 일에 맞춰 고른다"만 알면 된다.

개념 6 — 모델 자체를 다듬기 (모델 최적화)

망가지는 장면

"모델이 너무 커서 메모리에 안 들어가고, 들어가도 느리다."

모델이 무거우면 느리고 비싸다.

그러면 모델 자체를 가볍고 똑똑하게 고치면 된다.

일상비유

이삿짐 줄이기와 일꾼 솜씨 키우기.

짐(모델 크기)을 줄이면 옮기기 빨라진다.

그리고 한 글자씩 쓰는 답답한 버릇을 고치면(디코딩 개선) 더 빨라진다.

한 문장 정의 — 모델 최적화는 모델 자체를 손봐서 빠르고 싸게 만드는 일이며, 모델을 건드리므로 답 품질이 바뀔 수 있다.

세 갈래로 나뉜다.

(가) 모델 압축 — 짐 줄이기

• 양자화: 모델 속 숫자를 덜 정밀하게(32비트→16비트) 바꿔 짐을 절반으로. 쓰기 쉽고 효과 좋아 가장 인기.
• 증류: 큰 모델 흉내 내는 작은 모델 만들기.
• 프루닝: 별 도움 안 되는 부분을 잘라내기. 효과는 있지만 까다로워 실제로는 잘 안 씀.

(나) 한 글자씩 버릇 고치기 — 디코딩 개선

• 추측 디코딩(speculative decoding): 빠르지만 덜 똑똑한 초안 모델이 다음 글자들을 미리 써 본다. 그다음 진짜 모델이 한꺼번에 검사해서 맞은 데까지 받아들인다. 한 글자씩 만드는 것보다 빠르다. 품질은 그대로라 요즘 인기.
• 참조 기반 추론: 답에 들어갈 말이 입력에 이미 있으면(문서 인용·코드 수정 등), 새로 만들지 말고 그냥 복사.
• 병렬 디코딩: 앞 글자를 모르는 채로 여러 글자를 동시에 만들어 보고, 말 되는지 검사.

(다) 핵심 계산 손보기 — 어텐션 최적화

• KV 캐시: 글자 하나 만들 때 이전 글자들 계산을 다시 안 하고 저장해 둔 걸 재사용. 단, 글이 길수록 이 저장고가 커져 메모리를 잡아먹는다.
• 어텐션 재설계·커널: 계산 방식 자체를 가볍게 바꾸거나, 칩에 딱 맞는 빠른 코드(커널)를 짠다. 대표가 플래시 어텐션(FlashAttention) — 여러 계산을 하나로 묶어 빠르게.

단계별 예시

(1) 완성 예 — 추측 디코딩: 작은 초안 모델이 "I saw a dog ride in the bus"를 미리 쓴다. 진짜 모델이 한 번에 검사해 "...the"까지 맞다고 받아들이고, "car"는 직접 고쳐 쓴다. 한 글자씩 5번 만들 걸 한 번에 처리.

(2) 부분 완성 — 모델 속 숫자를 32비트에서 16비트로 줄이면 메모리 사용량이 ( )으로 준다. → 절반.

(3) 독립 적용 — 첨부 문서에 대해 질문하면 모델이 문서 내용을 그대로 인용하는 경우가 많다. 이때 그 말을 새로 만들지 않고 입력에서 복사해 속도를 높이는 기법 이름은? → 참조 기반 추론.

한 걸음 더 ▸ (지금 몰라도 됨) 멀티 쿼리 어텐션·그룹 쿼리 어텐션·페이지드 어텐션 같은 KV 캐시 절약 기술이 많다. 한 챗봇은 이런 기술 셋으로 KV 캐시를 20배 넘게 줄였다. 지금은 "이전 계산은 저장해 재사용한다"만 알면 된다.

개념 7 — 굴리는 법을 다듬기 (서비스 최적화)

망가지는 장면

"모델은 그대로인데, 요청을 한 줄로 세워 하나씩 처리하니 칩이 놀고 있다."

모델을 안 건드려도 빨라질 수 있다.

요청을 나르는 방식만 바꾸면 된다.

이 방식은 모델을 안 건드리니 답 품질도 안 바뀐다.

일상비유

버스 운행 짜기.

손님을 한 명씩 택시로 보내면(요청 하나씩) 차가 자꾸 빈 채로 다닌다.

여럿을 버스에 묶어 태우면(배치 처리) 한 번에 많이 나른다.

한 문장 정의 — 서비스 최적화는 모델은 그대로 두고 요청을 배분·묶는 방식만 바꿔 빠르고 싸게 만드는 일이며, 답 품질은 안 바뀐다.

핵심 기법 셋.

(가) 배치 처리 — 버스에 묶어 태우기

• 정적 배치: 자리 다 찰 때까지 기다렸다 출발. 첫 손님이 오래 기다림.
• 동적 배치: 정해진 시간 되면 출발(만석이면 더 일찍). 기다림을 통제.
• 연속 배치: 한 명 내리면 바로 다음 손님 태우기. 자리를 항상 채워 가장 효율적.

(나) 프리필-디코딩 분리

빠른 박자(프리필)와 느린 박자(디코딩)를 같은 칩에서 하면 서로 자원을 뺏는다.

그래서 둘을 다른 칩으로 나눠 따로 돌린다.

(다) 프롬프트 캐싱 — 겹치는 부분 미리 처리

요청마다 똑같이 들어가는 부분(시스템 프롬프트, 같은 긴 문서)을 매번 다시 처리하지 말고, 한 번 처리해 저장해 두고 재사용.

단계별 예시

(1) 완성 예 — 연속 배치: 배치에서 짧은 답(토큰 10개)이 먼저 끝나면 바로 사용자에게 보내고, 그 빈자리에 새 요청을 넣는다. 긴 답(토큰 1,000개)을 기다리느라 짧은 답이 늦어지는 일이 없다.

(2) 부분 완성 — 시스템 프롬프트가 1,000토큰이고 하루 100만 번 호출되면, 캐싱으로 하루에 약 ( )억 개의 반복 입력 처리를 아낀다. → 10.

(3) 독립 적용 — 모델은 안 건드리고 요청 나르는 방식만 바꿨다. 이 최적화로 답의 '품질'이 바뀔까? → 안 바뀐다.

한 걸음 더 ▸ (지금 몰라도 됨) 모델이 너무 커서 한 대에 안 들어가면 여러 칩에 쪼개 나눠 싣는다(텐서 병렬·파이프라인 병렬). 복제본을 여러 개 띄워 동시에 더 받는 방법(복제 병렬)도 있다. 지금은 "묶고·나누고·재사용한다"만 알면 된다.

단순 규칙

막혔을 때 순서대로 따라가면 된다.

1. 먼저 잰다. 어디가 느린지(연산이냐 데이터냐) 모르고 손대면 헛돈만 쓴다.
2. 싸고 쉬운 것부터. 양자화(짐 줄이기)와 배치 처리(버스에 묶기)가 보통 가장 잘 듣고 쉽다.
3. 모델을 건드리면 품질을 확인한다. 모델 최적화는 답이 바뀔 수 있으니 채점(평가)을 같이 한다.
4. 굴리는 법은 마음껏. 서비스 최적화는 모델을 안 건드리니 품질 걱정 없이 적용한다.

대부분의 경우에 가장 효과 큰 기법은 이 넷이다.

양자화·텐서 병렬·복제 병렬·어텐션 최적화.

더 해보기

최신 동향 (검증 2026-09-05) — 이 장이 가르치는 원리(짐 줄이기·버스에 묶기·계산 재사용)는 그대로 유효하다. 다만 실제로 쓰는 도구와 기법은 이 책에서 가장 빨리 바뀌는 부분이라, 아래 넷만 알아 두면 된다.

• 숫자를 줄이는 방식의 기본값이 바뀌었다. 예전에는 4비트 정수(INT4, AWQ)가 기본이었는데, 요즘 새 그래픽카드에서는 8비트 소수(FP8) 쪽이 기본에 가깝다. 4비트는 메모리가 아주 빠듯할 때 쓴다. 짐을 줄인다는 생각 자체는 같다.
• 미리 답을 찍어 보는 기법(추측 디코딩)은 이제 "해 볼 만한 아이디어"가 아니라 서빙 프로그램에 기본으로 들어가 있다.
• FlashAttention은 4세대까지 나왔다. 이 장에서 3세대로 배웠다면 숫자만 바꿔 기억하면 된다.
• vLLM 은 여전히 가장 널리 쓰이는 서빙 프로그램이고, 지금은 PyTorch 재단이 관리한다. 공식 문서는 docs.vllm.ai.

정리

• 똑똑해도 느리거나 비싸면 못 쓴다. 그래서 같은 답을 빠르고 싸게 받아낸다.
• 먼저 어디가 막혔는지 재고(지표), 막힌 곳을 뚫는다.
• 모델 자체를 다듬거나(품질 바뀜), 굴리는 법을 다듬거나(품질 그대로) 둘 중에 고른다.

다음 장에서는 지금까지 배운 조각들을 하나의 완성된 시스템으로 엮는 법을 본다. (지금 몰라도 됩니다.)

연습문제

1. 설명. 빠르고 싸게 만들기의 핵심을 처음 듣는 사람에게 한 문장으로 설명하라.
2. 구분. 두 개념(지연 시간, 처리량)을 실제 예시 하나로 구분하라.
3. 적용. 내 프로젝트나 학습 노트에서 이 장의 개념을 적용해 작게 개선할 지점을 하나 고르라.

부록 A. 쉬운 용어 사전

부록 C. 연습문제 풀이

1. 설명 예시. 빠르고 싸게 만들기는 거대 모델을 제품에 넣을 때 어떤 선택을 하고 어떻게 확인할지 판단하게 해 주는 장이다. 중요한 것은 용어를 외우는 것이 아니라, 이 개념이 어떤 입력·부품·결정에 영향을 주는지 말로 풀어 보는 것이다.
2. 구분 예시. 두 개념(지연 시간, 처리량)의 차이는 이렇게 잡으면 된다. 지연 시간은 한 요청의 빠름, 처리량은 많은 요청을 처리하는 힘이다. 실제 사례를 볼 때는 목적, 입력, 실패했을 때의 증상을 따로 적어 보면 헷갈리지 않는다.
3. 적용 예시. 가장 작은 개선부터 고른다. 예를 들어 이름을 더 분명히 하거나, 평가 기준을 한 줄 추가하거나, 직접 알 필요 없는 내부 정보를 감추는 식으로 시작한다. 한 번에 크게 갈아엎는 것보다 작은 변경 하나를 확인하며 진행하는 쪽이 입문 단계에 맞다.